Software Early Lifecycle – Functional Sizing

By Peter Hill, CEO, International Software Standards Benchmarking Group (ISBSG)

Introduction
Sizing a software project early in its lifecycle is not an easy task, but we often have to find an answer to the question: “How big is it?” Using functional units, there are a number of ways of establishing a rough size early in the life cycle of a project. Functional size measurement is now a widely accepted form of software sizing in industry, particularly in those companies that have reached the higher levels on the CMMI scale or certification to international standards. There are a number of functional size measurement (FSM) options available. The two FSM approaches that are used internationally are IFPUG and COSMIC FFP. Other approaches that conform to the ISO standard are primarily country based: NEMSA (Netherlands), FiSMA (Finland) and MARK ll (UK). The most commonly used FSM method to date, which is also the longest established, is the IFPUG (International Function Point User Group) method.

Although simple in concept, Functional Size Measurement is not a trivial task.

However, there are a large number of techniques available to provide estimates of the functional size of projects . In this article, we will explain the different levels of functional sizing and then look at some simple but effective ways of roughly determining the Functional Size of a project without doing a detailed function point count. As well as being used for software size estimation early in the life of a project, these techniques can be used as an introduction for those practitioners who do not currently use a functional size measure.

Sizing Levels: From Estimation to Detailed Functional Size Measurement
To get started on functional size measurement it helps to understand that there are a number of levels (See Table 1) of sizing which can be chosen depending upon the amount of information that is available about the project.

The advantages of estimating software size are countered to some extent by the possible lack of precision of the results. It is important to distinguish each measure as either “exact measure” (i.e. count) or “approximation” (i.e. estimate).

Table 1. Accuracy Levels for Software Sizing

A measurement can be conducted to a number of “accuracy levels”, based on:
• the purpose of the measurement and desired accuracy of the result
• the quality of project or application documentation available
• the time in which the measurement must be completed

Each size estimation technique can be classified based on the following characteristics (levels are listed from 1 to 6, reflecting decreasing levels of accuracy) listed in Table 1. During a project, it is likely that you will start with a Level 6 technique and move towards Level 1 as the project characteristics become better defined .

It is important to choose an estimation technique based on the documentation and time available plus the measurement purpose. Table 2 lists the basic attributes of each of the sizing levels, to help you to choose the one most suited to your need.

As the project progresses the size estimate should be validated and refined (eventually moving from low-accuracy to high-accuracy techniques).

Table 2. Basic Attributes of Sizing Levels

Some Practical Software Size Estimation Methods
There are a large number of software functional size estimation techniques available for levels 4 to 6 . Three practical and well-documented techniques are described here. These derived methods use some sort of algorithms.

1. Early Estimation of Functional Size Using the ISBSG Data
In the very early phases of a software development project it is not practical or even possible to know in detail all of the items that make up all of the function point components. However, it is often possible to detail one of the components with a fair degree of certainty - such as the Internal Logical Files or External Inputs.

It is likely that the functional component that you will have the most knowledge of is the Internal Logical Files. These closely resemble a count of the entities in a logical data model, modelled to second normal form. Even in the early phase of a project, (e.g. the Feasibility Study), it is often possible and very useful, to work with the client to develop a logical data model of the proposed application, as a means of assisting the client to define the requirements. When completed, this model can then be used to provide the starting point to establish the number of Internal Logical Files as part of the functional sizing.

An IFPUG function point count identifies all occurrences of the following five base functional component types, (BFC Types):
• Internal Logical Files (ILF) – data maintained by processes within the software
• External Interface Files (EIF) – data referenced by processes within the software
• External Inputs (EI) – processes which enter data to be stored internally within the software
• External Outputs (EO) - processes which extract derived data to be provided to the user
• External Queries (EQ) - processes which retrieve stored data to be provided to the user

Since the early days of the ISBSG project collection and analysis, it has been observed that the relationships between these five component types have remained relatively constant; i.e. each component type contributes a consistent percentage of the total function points in the overall total count for the application.

Investigation into the rationale for the relationships shows that there are good reasons why this consistency exists. It would be expected that for any complete ‘application’ which operates as a software ‘system’ the data that is entered, will be processed and stored for later retrieval. It therefore follows that we would expect a strong relationship between Input functions (data entered) and the Logical Files (internal data storage); and the Output and Query functions which retrieve data stored from the internal stores and the external stores, Interface Files.

The knowledge of these relationships has offered a number of valuable uses for the practitioner, one of which is the ability to predict the functional size of a new development project, or an implemented application, when the number of Internal Logical Files or External Inputs is known with any degree of certainty.

However, the relationships have only been found to be relevant to software that operates as a ‘self-contained’ system; i.e. a cohesive set of functionality that is loosely coupled with other applications.

For these reasons, it is not advisable to use the following early prediction sizing techniques to predict the size of any enhancement project that has a mix of added, changed and deleted functionality scattered over several functional areas within an application. This size estimation method is rated as a sizing Level 5.

Figure 1 shows the relationships between the five components of the IFPUG functional size method from project data in the ISBSG repository. These relationships can be used to estimate the functional size of a project.

The percentage values depict the relative contribution of each type for projects sized by IFPUG Version 4 functional sizing method and rated “A” or “B”.

Figure 1. Relationships Among IFPUG Functional Component Types

Use these relationships to estimate the functional size of a software development project:

Analysis of the ISBSG Repository also shows that most Internal Logical Files in applications are rated as being ‘low’ to medium’ in complexity. The mean score attributed to them across all projects is 8.6 function points.

Based upon the above, one can assume that the total score for the Internal Logical Files component of the function point count will be:
40 (ILFs) x 8.6 (mean score for Internal Logical Files) = 344 FPs

Figure 1 shows that the Internal Logical Files component of the function point count is typically around 21.7%. On this basis, the total functional size of the required application is predicted to be around:
344 FPs x 100/21.7 = 1,585 FPs

This would be best relayed to the customer as 1,590 FPs plus or minus 400 FPs*.

If the development project is to replace an existing application or delivers similar user functionality to another application then you may use some of the measures of components from these other applications as a guide.

Based upon the above, one can assume that the total score for the External Outputs component of the functional size measure will be:
50 (EOs) x 5.4 (mean score for External Outputs) = 270 FPs
Figure 1 shows that the External Outputs component of the functional size measure is typically around 25%. On this basis, the total functional size for the required application is predicted to be around:
270 FPs x 100/25 = 1,080 FPs

This would be best relayed to the customer as 1,100 FPs plus or minus 270 FPs*.

Note: The techniques discussed above are only valid if your application or development project is loosely coupled from other applications and fits the profile of projects currently in the ISBSG Repository. Early research indicates that the above relationships may not hold for the domains of real-time, control, scientific or embedded software.

2. KISS Quick Software Size Estimation Technique
KISS Quick is the functional size estimation approach related to the FiSMA functional size measurement method . KISS, (“Keep It Simple”), Quick is linked to IFPUG FP sizing by means of using average multipliers for the functional components. The first step in approximating functional size using KISS Quick is to complete a standard questionnaire (see Table 3) with 28 questions concerning the numbers of occurrences of functional components. The multipliers, which are then used to convert the number of functional components to actual FiSMA sizing units, are based on the specific measurement method (IFPUG only shown; multipliers equal zero where the method does not count that functionality type ). For typical MIS applications, KISS Quick provides typically an accuracy level 4 result for functional size.

3. EARLY & QUICK Software Sizing Technique
The Early & Quick Technique combines different approaches in order to provide better size estimates. It makes use of both analogical and analytical classification of functions and different levels of detail for different branches of the system, (aggregations and multilevel approach). The overall uncertainty level in the resulting functional size estimate, expressed as a range of minimum, likely, and maximum values, is the weighted sum of the individual components’ uncertainty levels. This technique provides a table of statistically validated values, derived from ISBSG and other sources. Due to its multi-level/mixed approach, the sizing level for E&Q depends on how many details the measurer has/can explore:

• Level 5 for higher hierarchical components (Macro processes, General Processes, Multiple & generic/unspecified Logical Data Groups)
• Level 4 for lower hierarchical components (Typical Processes, Base and Implicit Functional Processes; Internal and External Logical Data Groups with generic complexity)
• Level 3 (or Level 2, if the measurer even documents the link between data and processes) for portions where the Low/Average/ High complexity is determined.

* WARNING: Whether the above quick predictive technique is used or a detailed function point count is performed to establish size to be used for an early cost indicator for the project, a contingency of 20% to 30% should be added to allow for functionality not apparent early in the life cycle. Historical data indicates that this scope creep typically occurs because of additional functionality being identified as user requirements evolve in subsequent development phases.

Table 3. KISS Quick Questionaire

The starting point of this technique is the product breakdown structure of the system being studied, whose basic elements are the following software objects: - logical data groups (files)

- elementary (functional) processes Further aggregations are provided:
- logical data groups (files) can be grouped in multiple data groups
- elementary (functional) processes can be grouped in small, medium or large “typical” and “general” software processes
- general processes can be grouped in small, medium or large “macro” software processes Table 4 shows the descriptions for all the software objects and their aggregates. Each “software object” is assigned a size range based on statistical/analytical tables (depending on the referring measurement method). To estimate the functional size of a software system or project using this technique, a list of processes and data groups is all that is required, even comprising non-homogeneous levels of detail. Early & Quick functional size estimates may be denoted as “detailed”, “intermediate” or “summary”, depending on the detail level used for the early classification of functionalities. The following provides Early & Quick hints, levels and ranges for IFPUG measures:

Table 4. Software Objects Used in the Early & Quick Method

Early & Quick for IFPUG Function Point Size (E&QFP 2.0) IFPUG Data Functions and their E&Q Equivalent Logical Data Groups are identified for Internal Logical Files and External Interface Files. These groups are classified on a multiple scale of complexity:
• Low, Average, High, or generic (unspecified type),
• Low, Average, High, or generic (specified type: Internal or External),
• Low Multiplicity or High Multiplicity The first levels correspond exactly to those used by IFPUG, while multiplicity is used for particularly complex macro-files, grouping several distinct logical files. IFPUG Transactional Functions and Their E&Q Equivalent Base Functional Processes (BFPs) can be identified for External Inputs, External Outputs and External Queries, while Typical Processes, General Processes and Macro Processes are higher aggregations of Base Functional Processes. Accordingly:
• BFPs can be classified as Input (BFPI), Output (BFPO) or Query (BFPQ),
• Typically, General and Macro Processes are classified as small, average or large, depending on the estimated amount of their components. Due to the assigned minimum-maximum ranges, there is no need to evaluate the functional complexity of such processes, thus reducing the measurement effort.

Implicit functional processes (e.g. list boxes) can be treated in two ways:
• Direct estimation (one simple query per estimated instance)
• Derived estimation via an average correlation from the quantity of data groups (each query is typically populated by a logical data group).

Ranges and Numerical Assignments
Each Early & Quick FP element is assigned three estimated values (Unadjusted FP or UFP), i.e. minimum, likely and maximum UFP. Aggregated elements such as multiple data groups and general and macro processes are classified according to the ranges of their (estimated) subordinate components. Table 5 shows components ranges and numerical assignments for E&QFP 2.0.

Table 5. E&QFP 2.0 Components Ranges and Numerical Assignments

Early & Quick Summary
The general E&Q technique fully complies with the concepts, definitions and the structure of any functional size measurement method, as defined by ISO/IEC. Thus, this technique can be extended to any Functional Size Measurement method that is found to be compliant with the ISO/IEC standard. The E&Q technique has proved to be very effective, providing a result within ± 10% of the actual size in most cases, while the savings in measurement effort can be between 50% and 90% (depending on the aggregation level used, up to Macro Processes).

Using Functional Size to Estimate Project Effort and Duration
Once you have established your project’s approximate functional size expressed as a number of function points (or FSM units), you can use the ISBSG data to estimate the likely project effort and duration.

Summary & Tips
There are a large number of techniques available to provide estimates of the functional size of projects. In this article, we have explained the different levels of functional sizing and then looked at just three simple but effective ways of roughly determining the Functional Size of a project without doing a detailed function point count. It is important to remember that estimating functional size only results in an approximate size expressed in functional size units, it is not an estimate of effort, duration or cost. Always estimate using two different methods, (perhaps macro and micro), to reduce risk and provide cross checking. Express your estimates as a range, (worst case, likely, best case), or plus and minus a percentage.

The ISBSG software project repository currently contains data on 3,850 completed software projects. These projects have come from more than 20 countries and cover a large range of industries, applications, platforms and languages. Demographics of the ISBSG repository can be downloaded from the ISBSG website.

The ISBSG makes its data available and publishes books and analysis reports to help IT practitioners and IT customers better manage IT resources.

About the Author
Peter Hill is the CEO of the International Software Benchmarking Standards Group.

He has been in the Information Services industry for forty years with broad experience covering a number of industries including manufacturing, distribution, freight and aviation. He has worked in both Australia and New Zealand.

Mr Hill has been a speaker at conferences in Australia, China, Denmark, Finland, Malaysia, Netherlands, New Zealand, Spain and UK, with numerous articles published, covering key aspects of the Information Services industry. He is a past Chairman, Secretary and Fellow of the Victorian branch of the Australian Computer Society.

Mr Hill has compiled and edited five books for the ISBSG: “Software Project Estimation”, “The Benchmark Release 6”, “The Benchmark Release 8”, “Practical Project Estimation” and “The Software Metrics Compendium”. He runs courses on Project Management, with an emphasis on software acquisition projects and on the practical use of software metrics. He holds an MBA (Technology Management) from LaTrobe University.

Content contributors: Luca Santillo and Roberto Meli of the Italian Software Metrics Association, ISMA-GUFPI and Pekka Forselius of the Finnish Software Measurement Association.

Author Contact Information
Peter Hill, CEO, ISBSG
Ph: +61 3 96450369
Email: peter.r.hill@isbsg.org

GUFPI - ISMA (Gruppo Utenti Function Point Italia - Italian Software Metrics Association)
Contact: Dr Domenico Natale
Phone: +39-6-5025 2396
FAX: +39-6-50254190
E-mail: dnatale@sogei.it
Web Site: http://www.gufpi.org/

FiSMA (Finnish Software Measurement Association)
Mr Pekka Forselius
Phone: +35 8505 160416
FAX: +35 8934 42771
E-mail: pekkaf@sttf.fi